Other Properties
Description
Configure submission location info, what to do if there are no records in the List, the default value policy for new records, timestamp data, and more for a List's Detail View.
Submit location information
If checked, the user's location will be captured when List data is submitted. The user will be prompted on their device to allow access to the device location if this property is enabled.
Submit location information must be enabled in order to capture the user's location as part of the Detail View data.
To learn more, check out the videos below:
Geographic Data - Capturing Location Information when the User Edits Data
You can configure a List so that every time the user enters a new record, or edits a record, the user's location will be stored. This allows you to create applications where you capture the location of the device at the time a record was edited or entered.
In this video we show how this is done.
Schema for MySQL Table Used in Component
Geographic Data - Capturing Location Information when the User Synchronizes Data
You can capture location information at the time the user synchronizes the data. In this video who show how to configure the List to submit location information at the time the user synchronizes the List.
Schema for MySQL Table Used in Component
No record in List is selected action
This property allows you to specify the action if no record is currently selected (which can happen if the List's 'Allow null selection' property is not checked).
The options are:
None
do nothing. (Default action) When the UX is rendered no record in the List will be selected. The Detail View will be enabled and the user will be able to enter data into the Detail View. When the user clicks the 'Save' button, a new record will be added to the List. However, since the List's .NewDetailViewMethod() was not called, any default values for fields in new records will not be displayed in the Detail View.
NewRecord
The List's .NewDetailViewMethod() method will be called. If this method does not prevent the new record being shown, the Detail View will be enabled and the user can enter a new record. The default values for any fields in the Detail View will be shown. (Detail Values for fields in the Detail View are defined in the Fields pane of the List builder.)
DisableDetailView
The DetailView will be disabled. The user will have to either click on an existing row (in which case the Detail View will then be enabled, showing data from the selected row). or click the New Record button (in which case the Detail View will then be enabled, showing default values for fields).
Default values policy for new record in Detail View
When you define a List control with a Detail View you can specify Javascript code to return the default value for a field when a new record is created in the Detail View. You can specify the default value defined for the control to which the List field is bound is the default value used for new records.
For example, assume:
- You have a list with a field called FNAME
- You have a control in the List's Detail View called FIRSTNAME and the FNAME List field is mapped to this control
- In the List builder, you defined the following Javascript code for the FNAME field's default value: return 'Sam';
- The FIRSTNAME control has its Default value property set to 'Fred'.
When you click the New Record button in the List Detail View, the default value for the FIRSTNAME control (i.e. the control to which the FNAME List field is bound) will be set to 'Sam' because there was an explicit Default value rule set in the List builder. The default value of 'Sam' will be used even though the FIRSTNAME control defined a default value of 'Fred'.
However, assume that you now edit the List and delete the Default value Javascript code for the FNAME field. Now, when you create a new Detail View record, the default value shown in the FIRSTNAME control is governed by the setting of the Default values policy for new record in Detail View property in the List builder.
This property can either be set to:
- Option
- Description
- UseControlValue
(default) If no default value is defined in the List builder for the fie,d the default value defined in the control will be used.
- None
If no default value is defined in the List builder, the default will be blank and the default value set in the control will be ignored.
Use server-side synchronization log table
When you are working with disconnected data in a List control there is a small possibility of a synchronization request being submitted to the server more than once - resulting in the possibility of duplicate records in the database.
To understand how this might happen, consider what happens when the user clicks the 'Synchronize' button on a device to synchronize edits that were made while offline.
A JSON packet containing all of the edits that were made to the List (including any child Lists) is sent to the server.
The server processes the updates.
After the server has completed processing the updates, the server sends a response back to the client indicating which rows were successfully synchronized and which rows have errors. This response will set the 'dirty' state of each row in the List that had been edited back to 'clean'.
Obviously, in order for the server to receive the synchronization request, the user must have a connection. But suppose that AFTER the user sends a synchronization request to the server, but BEFORE the server completes the work and can send a response back to the client, the client looses connectivity.
The server will continue processing the updates to the server and will do all of the synchronization requests contained in the package sent from the client. The server does not know that the client is now offline and so, after it completes all of the work, it will send a response to client indicating which rows were successfully synchronized. However, since the client is now offline, the client will not receive this message from the server. This means that all of the rows on the client that were edited are still marked as 'dirty' (even though the server has successfully applied all of the edits).
Now assume that the client gets its connection back and the user clicks the 'Synchronize' button again. The client will send a JSON package to the server and this package will include all of the updates that were previously sent to the server.
In order to protect against this possibility, a special server-side log can be used to prevent synchronization commands from being executed more than once.
In order to turn on the server-side synchronization log, edit the List control and on the Detail View pane, check the Use server-side synchronization log table property.
Before you can check this property however, you must first define the setting for the Synchronization Log Table. To define these settings, click the Project Properties button when the Web Projects Control Panel has focus.
Scroll to the Offline Data Synchronization Log Table Settings section and set the properties for the table. You can map this table to an existing table in your SQL database or Alpha Anywhere can create a new table for you with the correct table structure.
Clear sync log table after successful sync
The synchronization log table helps prevents a sync command being processed more than once.
If you do offline-data entry in a List, there is a small chance that the SQL updates to the underlying table will be executed more than once. This can happen if the mobile device loses connectivity to the server AFTER the synchronize command has been received by the server, but BEFORE the mobile device has received the response from the server. Under this condition, the next time the List is synchronized, the previously submitted edits will be submitted a second time. By checking the 'Use server-side synchronization log table' property, a special server-side log can be used to prevent the possibility of duplicate SQL updates. When you check this property an extra Ajax callback fires after the client-receives acknowledgement from the server that the synchronization was performed.
By default, after a successful sync, the sync log table is cleared out.
The Clear sync log table after successful sync property, if checked, enables clearing the synchronization log automatically. This provides an extra level of protection against duplicate sync commands being executed by the server.
This property is only available if Use server-side synchronization log table is checked.
Use a 'timestamp' field when performing an Incremental Refresh
Normally, no schema changes are required to the database in order to perform an incremental refresh (i.e. there is no requirement that a timestamp field be added to the table).
An incremental refresh must compute which records on the server were changed since the last time the List was populated. In order to compute which records were changed the checksum (CRC) of the record contents on the server is compared with the checksum of the record on the device. If the checksum is different, the record was changed and an updated version of the record is sent to the server.
However, a more efficient way of determining if a record was changed is to query for all records modified since the highest timestamp value the last time the List was populated.
Now, if you have a timestamp field in your table, you can direct Alpha Anywhere to use this field for Incremental Updates, rather than the CRC (checksum) method.
To direct the List to use a timestamp field for incremental updates, open the List builder and go to the Detail View pane.
Then check the Use a 'timestamp' field when performing an Incremental Refresh property and then specify the name of the timestamp field.
Timestamp field
The name of the timestamp field to use. This property is only available if Use a 'timestamp' field when performing an Incremental Refresh is checked.